operator: KBS API for LUKS key registration by iroykaufman · Pull Request #248 · trusted-execution-clusters/operator

iroykaufman · 2026-05-04T15:31:15Z

Currently, every time the LUKS key is updated, the operator patches the trustee deployment, which causes a restart of the pod. This PR introduces a way to avoid this by setting the LUKS key using the KBS API.

Core implementation points:

Right before the trustee first deploys the operator, create an auth key for the KBS API and save it as a kube secret.
Replacing the patch mechanism with API calls
Add a reconcile loop that watches for changes in the trustee deployment and sync LUKS key that was lost.

Tests:

test_luks_key_sync - this test checks that the luks key is first sent to tustee and validates that after trustee restarts, the keys are sent again. Also, at the end, I delete one of the machines and check that the secret has been deleted.

Summary by Sourcery

Integrate KBS API–based LUKS key management for trustee, replacing deployment patching with authenticated API calls and adding automatic resync on trustee restarts.

New Features:

Introduce authenticated KBS API integration to store and manage per-machine LUKS keys instead of mounting secrets into the trustee deployment.
Add a controller that watches the trustee deployment and re-synchronizes all machine LUKS keys to KBS when the trustee becomes ready.
Generate and manage an Ed25519 keypair as a Kubernetes secret for authenticating KBS API access from the operator.

Enhancements:

Label and configure the trustee (KBS) service and deployment consistently via a shared label selector constant and updated volume templates.
Switch KBS resource storage to the kvstorage plugin and configure KBS admin to use the public auth key for API access.

Build:

Pin compute-pcrs-lib to a specific Git revision for reproducible builds and add kbs-client as a new operator dependency, along with installing perl in the container image for the build tooling.

Tests:

Add an end-to-end test that verifies initial LUKS key upload, re-sync after trustee restart, and LUKS key deletion on machine removal, plus unit tests for Ed25519 key generation.

Jakob-Naucke

Thank you for creating this, and thank you for already creating a test. Make sure that linting & build/unit tests pass.

Jakob-Naucke · 2026-05-06T14:36:16Z

+pub async fn launch_trustee_sync_controller(client: Client) {
+    let deployments: Api<Deployment> = Api::default_namespaced(client.clone());
+    let watcher_config = watcher::Config {
+        label_selector: Some("app=kbs".to_string()),


nit: maybe a constant also used in generate_kbs_{service,deployment} is better

Jakob-Naucke · 2026-05-06T14:38:11Z

 use serde::{Serialize, Serializer};
 use serde_json::{Value::String as JsonString, json};
 use std::collections::BTreeMap;
+use kbs_client;


Is this going to be https://github.com/confidential-containers/trustee/tree/main/tools/kbs-client?

iroykaufman · 2026-05-06T15:35:59Z

The CI is failing because we need to have some Perl dependency. I solved this by adding this RUN dnf install -y perl-FindBin perl-core to the containerfile. @Jakob-Naucke, any idea what the best approach is to solve it for the CI?

Jakob-Naucke · 2026-05-06T16:57:10Z

@iroykaufman these tests run in (Ubuntu) GHA containers that aren't affected by the Containerfile (this would get picked up in integration tests once I manage to fix them). You'll need to add them to the steps in .github/rust.yml:

steps:
  - name: "Install OpenSSL dependencies"
    run: apt-get install -y …

Jakob-Naucke · 2026-05-07T10:27:13Z

@iroykaufman whoops, you can set your own build container, and we do, and it's a Fedora container, so it should be dnf as usual. You did set it in the good place though afaict.

Jakob-Naucke · 2026-05-07T11:12:11Z

@iroykaufman thanks for the updates. integration tests are failing because these packages are missing there too. in my intuition, those shouldn't need to be built on the host at all so let me look into that first.

e: before the next push you can also still look into the lint failures

iroykaufman · 2026-05-07T11:21:07Z

@iroykaufman thanks for the updates. integration tests are failing because these packages are missing there too. in my intuition, those shouldn't need to be built on the host at all so let me look into that first.

Thanks, let me know and then I'll push with the lint fix

iroykaufman · 2026-05-07T11:37:53Z

@Jakob-Naucke maybe update the container file in buildroot with the openssl dependency is better then adding them in the github workflow files. WDYT?

Jakob-Naucke · 2026-05-07T11:47:01Z

@Jakob-Naucke maybe update the container file in buildroot with the openssl dependency is better then adding them in the github workflow files. WDYT?

Yes. I got confused by first thinking we were on GHA's Ubuntu containers, but the buildroot is the better place.

Jakob-Naucke · 2026-05-07T11:54:09Z

and the CI host does need these to compile the integration tests, which is slightly not how I thought cargo dependencies worked, but alas, these packages are now installed

iroykaufman · 2026-05-07T12:31:43Z

I deleted the changes for the github workflow and opened PR#9. When this is merged, the CI should work

alicefr · 2026-05-11T11:32:00Z

@sourcery-ai review

sourcery-ai · 2026-05-11T11:33:52Z

Reviewer's Guide

Implements KBS API–based LUKS key management so trustee no longer needs its deployment patched on each key update, introduces an auth keypair/secret for KBS, adds a controller to resync machine LUKS keys when trustee pods restart, switches KBS storage to kvstorage, and adds an end‑to‑end test covering LUKS key sync and deletion.

Sequence diagram for LUKS key registration via KBS API

sequenceDiagram
    actor User as ClusterOperator
    participant K8s as KubernetesAPI
    participant RegSrv as RegisterServerController
    participant Trustee as TrusteeModule
    participant KBS as KBSService

    User->>K8s: Create/Update Machine
    K8s-->>RegSrv: Machine event
    RegSrv->>RegSrv: keygen_reconcile
    RegSrv->>Trustee: generate_secret(client, id, owner_reference)
    Trustee->>K8s: Create Secret id (root key)
    K8s-->>Trustee: Secret id created

    RegSrv->>Trustee: send_secret(client, id)
    Trustee->>K8s: Get Secret id
    K8s-->>Trustee: Secret id (root data)
    Trustee->>K8s: Get Secret trustee-auth
    K8s-->>Trustee: Secret trustee-auth (private.key)
    Trustee->>KBS: set_resource(url, auth_key, resource_bytes, path, [])
    KBS-->>Trustee: 201 Created
    Trustee-->>RegSrv: Ok
    RegSrv-->>K8s: Reconcile result Action::await_change()

Sequence diagram for LUKS key resync on trustee restart

sequenceDiagram
    participant K8s as KubernetesAPI
    participant SyncCtl as TrusteeSyncController
    participant TrusteeDep as TrusteeDeployment
    participant Trustee as TrusteeModule
    participant KBS as KBSService

    Note over TrusteeDep,K8s: TrusteeDeployment restarted
    K8s-->>SyncCtl: Deployment event (label app=kbs)
    SyncCtl->>SyncCtl: trustee_deployment_reconcile
    SyncCtl->>TrusteeDep: Read status (ready_replicas, replicas)
    TrusteeDep-->>SyncCtl: Status ready
    SyncCtl->>Trustee: sync_all_machine_luks_key(client)

    Trustee->>K8s: List Secrets (default namespace)
    K8s-->>Trustee: Secrets owned by Machines
    loop For each machine Secret id
        Trustee->>Trustee: send_secret(client, id)
        Trustee->>K8s: Get Secret id
        K8s-->>Trustee: Secret id (root data)
        Trustee->>K8s: Get Secret trustee-auth
        K8s-->>Trustee: Secret trustee-auth (private.key)
        Trustee->>KBS: set_resource(url, auth_key, resource_bytes, path, [])
        KBS-->>Trustee: Response
    end
    Trustee-->>SyncCtl: Ok
    SyncCtl-->>K8s: Action::await_change()

Sequence diagram for LUKS key deletion via KBS API

sequenceDiagram
    participant K8s as KubernetesAPI
    participant RegSrv as RegisterServerController
    participant Trustee as TrusteeModule
    participant KBS as KBSService

    K8s-->>RegSrv: Machine deletion event
    RegSrv->>RegSrv: keygen_reconcile finalizer
    RegSrv->>Trustee: delete_secret(client, id)
    Trustee->>K8s: Get Secret trustee-auth
    K8s-->>Trustee: Secret trustee-auth (private.key)
    Trustee->>KBS: delete_resource(url, auth_key, path, [])
    KBS-->>Trustee: 200 OK
    Trustee-->>RegSrv: Ok
    RegSrv-->>K8s: Finalizer completed (Action::await_change())

Class diagram for new Ed25519 key pair and trustee auth secret generation

classDiagram
    class Ed25519KeyPair {
        +Vec~u8~ private_key_pem
        +Vec~u8~ public_key_pem
    }

    class TrusteeModule {
        +generate_ed25519_key_pair() Result~Ed25519KeyPair~
        +generate_trustee_auth_keys_secret(client, owner_reference) Result~()~
        +get_auth_key(client) Result~String~
        +send_secret(client, id) Result~()~
        +delete_secret(client, id) Result~()~
        +sync_all_machine_luks_key(client) Result~()~
        +launch_trustee_sync_controller(client) void
    }

    TrusteeModule --> Ed25519KeyPair : creates

File-Level Changes

Change	Details	Files
Replace trustee deployment patching with KBS API calls for LUKS key lifecycle (create/sync/delete).	Introduce get_auth_key helper to read the trustee auth private key from a namespaced Kubernetes Secret Implement send_secret to fetch machine LUKS key Secret data and call kbs_client::set_resource against the KBS HTTP endpoint Implement delete_secret to remove machine LUKS key resources via kbs_client::delete_resource Update keygen_reconcile to use send_secret on create and delete_secret on cleanup instead of mount_secret/unmount_secret, and improve cleanup error reporting	`operator/src/trustee.rs` `operator/src/register_server.rs` `operator/src/kbs-config.toml` `operator/src/main.rs` `operator/Cargo.toml` `lib/src/endpoints.rs`
Add trustee auth keypair generation and wiring so KBS API is authenticated via Ed25519 public key and key material is mounted into KBS pods.	Add Ed25519KeyPair type and generate_ed25519_key_pair helper with tests validating PEM format and uniqueness Implement generate_trustee_auth_keys_secret to create the trustee-auth Secret with private and public keys owned by the cluster Extend KBS volume templates to mount the trustee-auth Secret under /key, exposing only the public key file Update kbs-config.toml admin section to use auth_public_key=/key/public.pub and switch the resource plugin type to kvstorage Set the KBS deployment label selector to use the KBS_LABEL_SELECTOR constant and apply matching labels on the Deployment	`operator/src/trustee.rs` `operator/src/kbs-config.toml` `operator/src/main.rs` `lib/src/endpoints.rs` `tests/Cargo.toml`
Introduce a trustee deployment watcher/controller that resynchronizes all machine LUKS keys to KBS when trustee becomes ready.	Add sync_all_machine_luks_key to enumerate Machine-owned Secrets and push each to KBS via send_secret with logging and per-secret error handling Implement trustee_deployment_reconcile to detect when the trustee Deployment has desired ready replicas and then trigger a full machine LUKS key resync Add launch_trustee_sync_controller to start a kube-runtime Controller watching Deployments labeled with app=KBS_LABEL_SELECTOR, and wire it into main() startup	`operator/src/trustee.rs` `operator/src/main.rs` `lib/src/endpoints.rs`
Extend test coverage with an end-to-end LUKS key sync scenario and expose a helper for waiting on Deployment readiness.	Add test_luks_key_sync integration test that creates two Machines, waits for their Secrets, verifies both are sent to KBS from operator logs, restarts the trustee Deployment and checks resync logs, deletes one Machine and confirms its secret is removed from KBS, and performs cleanup Expose TestContext::wait_for_deployment_ready as pub so tests can wait for trustee Deployment readiness	`tests/trusted_execution_cluster.rs` `test_utils/src/lib.rs`
Tidy up dependencies and build/test support for the new KBS client and tests.	Pin compute-pcrs-lib to a specific git revision for reproducibility Add kbs-client git dependency to the operator crate for calling the KBS API Add chrono as a test dependency to support timestamped deployment restarts Install perl in the Containerfile to satisfy new build or test requirements	`Cargo.toml` `operator/Cargo.toml` `tests/Cargo.toml` `Containerfile` `Cargo.lock`

Tips and commands

Interacting with Sourcery

Trigger a new review: Comment @sourcery-ai review on the pull request.
Continue discussions: Reply directly to Sourcery's review comments.
Generate a GitHub issue from a review comment: Ask Sourcery to create an
issue from a review comment by replying to it. You can also reply to a
review comment with @sourcery-ai issue to create an issue from it.
Generate a pull request title: Write @sourcery-ai anywhere in the pull
request title to generate a title at any time. You can also comment
@sourcery-ai title on the pull request to (re-)generate the title at any time.
Generate a pull request summary: Write @sourcery-ai summary anywhere in
the pull request body to generate a PR summary at any time exactly where you
want it. You can also comment @sourcery-ai summary on the pull request to
(re-)generate the summary at any time.
Generate reviewer's guide: Comment @sourcery-ai guide on the pull
request to (re-)generate the reviewer's guide at any time.
Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
pull request to resolve all Sourcery comments. Useful if you've already
addressed all the comments and don't want to see them anymore.
Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
request to dismiss all existing Sourcery reviews. Especially useful if you
want to start fresh with a new review - don't forget to comment
@sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

Enable or disable review features such as the Sourcery-generated pull request
summary, the reviewer's guide, and others.
Change the review language.
Add, remove or edit custom review instructions.
Adjust other review settings.

Getting Help

Contact our support team for questions or feedback.
Visit our documentation for detailed guides and information.
Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

sourcery-ai

Hey - I've found 2 issues, and left some high level feedback:

In launch_trustee_sync_controller, the watcher label_selector is set as "app={KBS_LABEL_SELECTOR}", which will not expand the constant and thus never match your KBS pods; this should be built with format!("app={KBS_LABEL_SELECTOR}") or similar.
The new test_luks_key_sync relies on grepping operator logs for specific hard-coded message substrings (including the exact count "Syncing 2 machine luks key to KBS"), which makes the test brittle to benign log or wording changes; consider asserting behavior via the KBS state or Kubernetes resources instead of log contents where possible.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In `launch_trustee_sync_controller`, the watcher `label_selector` is set as `"app={KBS_LABEL_SELECTOR}"`, which will not expand the constant and thus never match your KBS pods; this should be built with `format!("app={KBS_LABEL_SELECTOR}")` or similar.
- The new `test_luks_key_sync` relies on grepping operator logs for specific hard-coded message substrings (including the exact count `"Syncing 2 machine luks key to KBS"`), which makes the test brittle to benign log or wording changes; consider asserting behavior via the KBS state or Kubernetes resources instead of log contents where possible.

## Individual Comments

### Comment 1
<location path="operator/src/trustee.rs" line_range="244" />
<code_context>
+pub async fn launch_trustee_sync_controller(client: Client) {
+    let deployments: Api<Deployment> = Api::default_namespaced(client.clone());
+    let watcher_config = watcher::Config {
+        label_selector: Some("app={KBS_LABEL_SELECTOR}".to_string()),
+        ..Default::default()
+    };
</code_context>
<issue_to_address>
**issue (bug_risk):** The label selector string is not interpolating `KBS_LABEL_SELECTOR` and will not match any pods.

Because the selector is the literal string `"app={KBS_LABEL_SELECTOR}"`, the controller will never match any `kbs`-labelled resources. Build the selector string dynamically (e.g. `format!("app={}", KBS_LABEL_SELECTOR)` or a const with the expanded value) so it actually aligns with the deployment and service labels.
</issue_to_address>

### Comment 2
<location path="tests/trusted_execution_cluster.rs" line_range="604-613" />
<code_context>
+    // Delete machine1 and verify its secret is removed from both K8s and KBS
</code_context>
<issue_to_address>
**issue (testing):** Also assert that the machine Secret is deleted from Kubernetes, not only from KBS logs

Right now the test only checks the operator logs for `"Secret {id1} deleted successfully"`, which covers the KBS side. To match the comment and fully validate behavior, please also assert that the corresponding Kubernetes Secret no longer exists (for example, `secrets_api.get(&machine1_uuid).await` returns `NOT_FOUND` or fails via the Poller).
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

Jakob-Naucke

If changes to the base branch made a rebase necessary, the usual practice is to fix and keep the existing commits, so I think you can squash in this instance.
Pushing new buildroots got auto-disabled due to inactivity (the more you know). I re-enabled it so FindBin etc. are hopefully there on next attempt.

Jakob-Naucke · 2026-05-15T09:37:56Z


 [admin]
-type = "DenyAll"
+type = "Simple"


Sorry about this one, didn't see it coming but you fixed it :)

iroykaufman · 2026-05-15T13:02:17Z

If changes to the base branch made a rebase necessary, the usual practice is to fix and keep the existing commits, so I think you can squash in this instance.

This is still WIP so I'll squash it into one commit after everything is fixed.

alicefr · 2026-05-21T11:04:25Z

@iroykaufman can you please split the git history into multiple commits to make the review easier

alicefr · 2026-07-01T12:50:41Z

@iroykaufman can you please also split the commit 774f99b into multiple It does too many things in one. I would at least split the bump of the kbs-client version and the configuration into a separate commit.

@iroykaufman was the problem that the kbs-client won't work as used here with 17? if it does work, I agree. if it doesn't, I prefer big commits over breaking bisects @alicefr

Correct. When bumping to trustee v0.20.0, it didn't work as is because the trustee storage backend changed. The idea was to use the API as an abstraction layer that could make it much easier to bump trustee to a later version or change the storage backend in the future.

But is the old behavior of using config map for secrets, AK and RV still supported by 0.20? Or did they suddenly move and only support adding the various objects via API?

Trustee v0.20.0 replaced file-based configuration with a KV storage backend that Trustee manages internally it reads and writes to its own storage directories (e.g. /opt/trustee/storage/kbs/, /opt/trustee/storage/reference_value/). While it is still possible to mount these files with some extra effort, doing so in this version and moving forward does not appear to be the correct approach.

I didn't ask because I want to keep the old behavior, but if the mounting of the secrets and other objects still works, we could gradually add each component one by one in separate commits. In this way, we keep the git bisect working but the PR becomes a bit more readable

iroykaufman · 2026-07-01T13:31:40Z

@iroykaufman can you please also split the commit 774f99b into multiple It does too many things in one. I would at least split the bump of the kbs-client version and the configuration into a separate commit.

@iroykaufman was the problem that the kbs-client won't work as used here with 17? if it does work, I agree. if it doesn't, I prefer big commits over breaking bisects @alicefr

Correct. When bumping to trustee v0.20.0, it didn't work as is because the trustee storage backend changed. The idea was to use the API as an abstraction layer that could make it much easier to bump trustee to a later version or change the storage backend in the future.

But is the old behavior of using config map for secrets, AK and RV still supported by 0.20? Or did they suddenly move and only support adding the various objects via API?

Trustee v0.20.0 replaced file-based configuration with a KV storage backend that Trustee manages internally it reads and writes to its own storage directories (e.g. /opt/trustee/storage/kbs/, /opt/trustee/storage/reference_value/). While it is still possible to mount these files with some extra effort, doing so in this version and moving forward does not appear to be the correct approach.

I didn't ask because I want to keep the old behavior, but if the mounting of the secrets and other objects still works, we could gradually add each component one by one in separate commits. In this way, we keep the git bisect working but the PR becomes a bit more readable

I understand, initially I tried to do exactly that, but the file formats also changed (you can choose to use either JSON or individual files). If I remember correctly, we use both formats: JSON for reference values and individual files for secrets. Because of this, it will create some extra work that will need to be reverted later. Maybe I missed things but this is what I stumbled upon.

uril · 2026-07-01T17:49:24Z

Trustee v0.20.0 can still keep configuration files on its file-system, so it is possible to update to 0.20.0 first
As Roy mentioned it would take some adjustments of configuration files -- for example reference-values from json to files - each PCR has a separate file, instead of a single json file, and those adjustments will be overwritten by following patches.

alicefr · 2026-07-02T07:18:41Z

@uril @iroykaufman thanks for the explication! No, I don't want you to do useless extra work. Let's keep it in this way then.

uril · 2026-07-02T17:51:45Z

@alicefr @iroykaufman we'll check again how much work it is to do the trustee upgrade to 0.20.0 before/after the API change. It would be nicer to have them in separate commits.

iroykaufman · 2026-07-08T08:17:22Z

I want to summarize the comments and outline the actions I took:

Integrate reflector: I started implementing this, but it turned out to be a relatively large change. This is because I need to forward the context from main to all the necessary functions. For example, launch_rv_image_controller and launch_rv_job_controller now need to accept AkContextData for image_reconcile, among other things. I prefer to submit this change as a separate PR.
Avoid log checks in the integration tests: I understand the motivation here is to prevent tests from failing if log messages change. However, the alternative approach, executing into the pod to check if resources are populated raises a similar issue and could actually be worse. If the file locations change, the test will still fail, but the added complexity will make it harder to debug and fix. With log checks, fixing a failure simply requires updating the expected log string.
All other comments are resolved.
As @uril mentioned, I'll try to do the trustee upgrade to v0.20.0 before/after the API change.
If there is anything I miss, let me know

openshift-ci · 2026-07-08T08:25:07Z

New changes are detected. LGTM label has been removed.

alicefr · 2026-07-14T11:31:05Z

I want to summarize the comments and outline the actions I took:

Integrate reflector: I started implementing this, but it turned out to be a relatively large change. This is because I need to forward the context from main to all the necessary functions. For example, launch_rv_image_controller and launch_rv_job_controller now need to accept AkContextData for image_reconcile, among other things. I prefer to submit this change as a separate PR.

That's ok.

Avoid log checks in the integration tests: I understand the motivation here is to prevent tests from failing if log messages change. However, the alternative approach, executing into the pod to check if resources are populated raises a similar issue and could actually be worse. If the file locations change, the test will still fail, but the added complexity will make it harder to debug and fix. With log checks, fixing a failure simply requires updating the expected log string.

The log don't actually check the actual result but only that the part of the code was run. I still think checking the secrets in the filesystem will be better. Or as an alternative. you could run kbs-client from a container and query the object from the API and see that they are effectively gone. If this complicates the PR too much, we can leave the log and refactor it later. @Jakob-Naucke WDYT?

alicefr · 2026-07-14T12:12:55Z

@iroykaufman for the rest, it isn't clear to me if this is ready for review or you want first try to split the trustee bump? thanks!

Jakob-Naucke · 2026-07-14T13:46:18Z

Avoid log checks in the integration tests: I understand the motivation here is to prevent tests from failing if log messages change. However, the alternative approach, executing into the pod to check if resources are populated raises a similar issue and could actually be worse. If the file locations change, the test will still fail, but the added complexity will make it harder to debug and fix. With log checks, fixing a failure simply requires updating the expected log string.

The log don't actually check the actual result but only that the part of the code was run. I still think checking the secrets in the filesystem will be better. Or as an alternative. you could run kbs-client from a container and query the object from the API and see that they are effectively gone. If this complicates the PR too much, we can leave the log and refactor it later. @Jakob-Naucke WDYT?

I too could see Trustee change the structure, so maybe kbs-client > logs > filesystem. I agree it can be a TODO & future PR

iroykaufman · 2026-07-15T06:19:45Z

I want to summarize the comments and outline the actions I took:

Integrate reflector: I started implementing this, but it turned out to be a relatively large change. This is because I need to forward the context from main to all the necessary functions. For example, launch_rv_image_controller and launch_rv_job_controller now need to accept AkContextData for image_reconcile, among other things. I prefer to submit this change as a separate PR.

That's ok.

Avoid log checks in the integration tests: I understand the motivation here is to prevent tests from failing if log messages change. However, the alternative approach, executing into the pod to check if resources are populated raises a similar issue and could actually be worse. If the file locations change, the test will still fail, but the added complexity will make it harder to debug and fix. With log checks, fixing a failure simply requires updating the expected log string.

The log don't actually check the actual result but only that the part of the code was run. I still think checking the secrets in the filesystem will be better. Or as an alternative. you could run kbs-client from a container and query the object from the API and see that they are effectively gone. If this complicates the PR too much, we can leave the log and refactor it later. @Jakob-Naucke WDYT?

As I understand and from what I checked, the log is only printed when the API call is successful. For example, in send_secret there is a call to kbs_client::set_resource(..) if the call was successful and trustee got the resource, the function will return ok and error otherwise. Only if the return value is ok the success log message will be printed.

iroykaufman · 2026-07-15T06:23:47Z

@iroykaufman for the rest, it isn't clear to me if this is ready for review or you want first try to split the trustee bump? thanks!

I'll give it a try today for splitting the commits. I'll let you know when it's ready

Signed-off-by: Roy Kaufman <rkaufman@redhat.com>

All trustee resources, including the resource policy, attestation policy, RV, LUKS key, and AK, are now synchronized using the KBS API. The main motivation for this is replacing the patch mechanism that causes a restart of the trustee deployment. Also, this abstraction over the trustee backend simplifies the process of upgrading to future versions of trustee. Config: - Update kbs-config.toml to v0.20.0 format - Store reference values in dedicated ConfigMap (trustee-rv-data) instead of trustee-data API-driven resource management: - Add KBS API client functions: send_secret, delete_secret, register_ak, sync_resource_policy, sync_attestation_policy, sync_reference_values - Replace volume-mount approach for secrets with KBS API calls - Add trustee deployment reconciler that syncs policies, reference values, and secrets when deployment becomes available Dependencies: - Add kbs-client and jsonwebtoken crates - Bump trustee image tag to v0.20.0 Signed-off-by: Roy Kaufman <rkaufman@redhat.com>

test_luks_key_sync - verify the initial LUKS key upload, re-sync after trustee restart, and LUKS key deletion on machine removal. test_attestation_key_sync - verify that attestation keys are registered with the KBS and re-registered after trustee restarts. Signed-off-by: Roy Kaufman <rkaufman@redhat.com>

Tested functions: - sync_all_machine_luks_key - update_attestation_keys Signed-off-by: Roy Kaufman <rkaufman@redhat.com>

iroykaufman · 2026-07-15T15:25:23Z

@alicefr @Jakob-Naucke, this is a status update on splitting the commits: I tried bumping trustee to v0.20.0 and using mount instead of the API calls. However, this introduces additional changes (not a very small amount because of the format change of the files) that will be deleted. I also tried keeping trustee on v0.17.0 and applying the three patches (such as the delete option) on trustee. This creates some merge conflicts on the trustee side that I will need to resolve. It is a bit challenging but doable. The main issue is that those commits will only work with this specific build of trustee. If you feel the current state of the PR is manageable to review, let me know. Otherwise, please don't hesitate to let me know, and I will implement one of the first two options, or if there is a different option, I'm happy to hear it.

On a separate note, I updated the whitelist of dependencies to the ones that came with kbs-client to the allowlist, but I am not sure how to verify if they are permitted by Fedora.

Jakob-Naucke · 2026-07-15T15:41:00Z

It is a bit challenging but doable. The main issue is that those commits will only work with this specific build of trustee. If you feel the current state of the PR is manageable to review, let me know.

It's a hard read but I think we could review as is. It's worth knowing that a split will be many more lines changed than its rollup (IIUC). @alicefr WDYT?

On a separate note, I updated the whitelist of dependencies to the ones that came with kbs-client to the allowlist, but I am not sure how to verify if they are permitted by Fedora.

I'm afraid that many wouldn't be, but we can also fix this separately, as we are for oci-client. I'm sorry for insisting on adding the feature earlier -- I didn't expect this rabbit hole to be so deep.

Jakob-Naucke reviewed May 6, 2026

View reviewed changes

iroykaufman force-pushed the luks-key branch 2 times, most recently from dc726d8 to c5ec81d Compare May 6, 2026 15:22

iroykaufman force-pushed the luks-key branch from 3f377eb to 4f7a366 Compare May 7, 2026 10:38

Jakob-Naucke mentioned this pull request May 7, 2026

Update transition time only on new status #238

Merged

iroykaufman mentioned this pull request May 7, 2026

Add OpenSSL dependencies trusted-execution-clusters/buildroot#9

Merged

iroykaufman force-pushed the luks-key branch from 4f7a366 to 472438d Compare May 7, 2026 12:31

openshift-ci Bot added the needs-rebase label May 7, 2026

sourcery-ai Bot reviewed May 11, 2026

View reviewed changes

Comment thread operator/src/trustee.rs Outdated

Comment thread tests/trusted_execution_cluster.rs

iroykaufman force-pushed the luks-key branch 2 times, most recently from a751ea3 to eeb4005 Compare May 14, 2026 14:03

openshift-ci Bot removed the needs-rebase label May 14, 2026

Jakob-Naucke reviewed May 15, 2026

View reviewed changes

iroykaufman force-pushed the luks-key branch 4 times, most recently from 9c68c4b to 7dd60c7 Compare May 21, 2026 11:03

Jakob-Naucke mentioned this pull request Jul 2, 2026

trusted-execution-clusters: Introduce Azure tests openshift/release#79393

Draft

Jakob-Naucke mentioned this pull request Jul 7, 2026

Extend no-rustls test #301

Open

iroykaufman force-pushed the luks-key branch from 2bef27f to b257e02 Compare July 8, 2026 08:25

openshift-ci Bot removed the lgtm label Jul 8, 2026

iroykaufman force-pushed the luks-key branch 5 times, most recently from bd9a8ed to bb7369f Compare July 9, 2026 18:06

openshift-ci Bot added the needs-rebase label Jul 15, 2026

iroykaufman added 4 commits July 15, 2026 09:33

trustee: Add key pair as a base to use kbs API

d0b2f79

Signed-off-by: Roy Kaufman <rkaufman@redhat.com>

trustee: Add unit tests

e1b2d9f

Tested functions: - sync_all_machine_luks_key - update_attestation_keys Signed-off-by: Roy Kaufman <rkaufman@redhat.com>

iroykaufman force-pushed the luks-key branch from bb7369f to e1b2d9f Compare July 15, 2026 14:35

openshift-ci Bot removed the needs-rebase label Jul 15, 2026

Uh oh!

Conversation

iroykaufman commented May 4, 2026 • edited by sourcery-ai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Core implementation points:

Tests:

Summary by Sourcery

Uh oh!

Jakob-Naucke left a comment

Choose a reason for hiding this comment

Uh oh!

Jakob-Naucke May 6, 2026

Choose a reason for hiding this comment

Uh oh!

Jakob-Naucke May 6, 2026

Choose a reason for hiding this comment

Uh oh!

iroykaufman May 6, 2026

Choose a reason for hiding this comment

Uh oh!

iroykaufman commented May 6, 2026

Uh oh!

Jakob-Naucke commented May 6, 2026

Uh oh!

Jakob-Naucke commented May 7, 2026

Uh oh!

Jakob-Naucke commented May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

iroykaufman commented May 7, 2026

Uh oh!

iroykaufman commented May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Jakob-Naucke commented May 7, 2026

Uh oh!

Jakob-Naucke commented May 7, 2026

Uh oh!

iroykaufman commented May 7, 2026

Uh oh!

alicefr commented May 11, 2026

Uh oh!

sourcery-ai Bot commented May 11, 2026

Reviewer's Guide

Sequence diagram for LUKS key registration via KBS API

Sequence diagram for LUKS key resync on trustee restart

Sequence diagram for LUKS key deletion via KBS API

Class diagram for new Ed25519 key pair and trustee auth secret generation

File-Level Changes

Interacting with Sourcery

Customizing Your Experience

Getting Help

Uh oh!

sourcery-ai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Jakob-Naucke left a comment

Choose a reason for hiding this comment

Uh oh!

Jakob-Naucke May 15, 2026

Choose a reason for hiding this comment

Uh oh!

iroykaufman commented May 15, 2026

Uh oh!

alicefr commented May 21, 2026

Uh oh!

alicefr commented Jul 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

iroykaufman commented Jul 1, 2026

Uh oh!

uril commented Jul 1, 2026

Uh oh!

alicefr commented Jul 2, 2026

Uh oh!

uril commented Jul 2, 2026

Uh oh!

iroykaufman commented Jul 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

iroykaufman commented May 4, 2026 •

edited by sourcery-ai Bot

Loading

Jakob-Naucke commented May 7, 2026 •

edited

Loading

iroykaufman commented May 7, 2026 •

edited

Loading

alicefr commented Jul 1, 2026 •

edited

Loading

iroykaufman commented Jul 8, 2026 •

edited

Loading

iroykaufman commented Jul 15, 2026 •

edited

Loading